An example of kindness in tech: the case of "shitty code"

This article is an essay about kindness and how to bring it as a manager. It showcase an example: the software engineer saying "shitty code" ruthlessly.

Disclaimer: this article shows my opinion and is not intended to be an absolute truth. So all constructive feedbacks are welcome !

Introduction

During my short career, I saw countless times a developer picking at the code and yelling or mumbling to himself "what a shitty code". We all have gone through it, me the first. Even Robert C. Martin considered it as a metric of "bad code" in the book Clean Code ! However, as the years passed I questioned myself about this expression. "Shitty code"... There is no kindness in it, only pure emotional frustration and disdain. So, how can we judge code ? should we qualify it as shitty without further explanations or else ? And if we go deeper, what is a code of great quality ?

The issue of the expression

Apart from the disappointment, this expression brings no constructive value: no explanation, no will to help your colleague be a better professional and is pure judgment. Moreover, it is also a dangerous expression because it can bring tension in the team. How your colleague would react if you say that to the code he just wrote ? Even if we look for less ego in our sector, no one would be happy to hear that.

Even if you are in the perfect team (ie a team that has no ego or very little), you would have a remark.

But the egoless principle says that we should be hard to the code and kind to the people. So has I am not targeting a person, just saying that this code is shit, there is no need to be sensitive about it.

As a member of the team, it can make sense. However, as a manager perspective, it can be poisonous. Unless you are a buddhist monk or a self-accomplished man with nothing to prouve, ego will always twist it and can potentially damage the team inter-relationships.

Moreover, this sentence is a nonsense in my opinion. The perception of good and bad practices vary over time. A good code in the 2000's can be considered as a bad one 20 years later. One example is that in the 90's it was common to put business rules in the database layer with procedures. Now, it is presented as an antipattern because of its difficulty to maintain and unit test.

Another aspect often overlooked is that going quick and dirty can be useful or even necessary. A startup that is looking to validate its business model puts velocity first and quality second at best. In that case, buying technical debt is a choice. the MVP won't be perfect or well-designed and structured and that's fine ! At that stage we are not looking to create a masterpiece but to quickly deliver value to the customer and be resilient and agile.

Some TDD experts will argue that TDD is the way to unify velocity and quality in software development but this kind of profile is very rare and hard to hire for a startup I would say. So I consider that the average developer goes faster with the old quick and dirty philosophy

So, talking about "shitty" code is very tricky because of its very contextualized use.

The danger of this expression

At first sight, we would say that as everyone says it, so it can be considered as normal. But it can bring you 2 issues in the long run:

• prevents you from creating a "psychologically safe" area
• having access to candid feedbacks which can hinder your team and prevent the team from reaching its full potential and productivity.

Many researches shows that the number one criteria of good teams is Psychological Safety. How a manager can create a safe zone if at anytime someone can shout that the code written is "shitty" ? Sure, psychological safety is about talking openly, but it also embarks a notion of respect and no judgment.

As a manager, how to deal with ?

If you stumble into this kind of case, and you see that it makes the team uncomfortable, the worst case would be to minimise it and let it go for the reasons explained above. I advised you to do a 1:1 meeting with the person to explain him.

if your team struggles, you can use a workaround. I often saw the term suboptimal code. it is not perfect and can bring to many discussion (or disputes) but it is the best consensus I found. If you plan on removing the word, the transition has to be smooth. One idea can be to turn it into some kind of joke or game in the team. For instance, when someone says the "s-word", immediately he brings the croissant the next day (yes I am French ! :D) or other fancy stuff.

Afterward, if you see that this word federates your foes, you can keep it as part of the team culture. On the contrary, you can try to remove it.

As a developer, what should I do ?

No need to look for complex solutions; just stay neutral and non-offensive by explaining about the reasons you think this code need to be improved and how is enough. It delights the conversation and make your colleague grow.

Conclusion

In this short essay, we tried to explain what could be the reasons why the expression "shitty code" has to be prohibited. We presented the potentials harms to your teammates and how to resolve it. We finished with an attempt to find a workaround expression.

TL;DR

• don't use it, it's harmful
• stay neutral and constructive
• don't let it go if you hear it
• you can use "suboptimal code" as a replacement